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From the Editor 


When we launched ConneXions seven years ago, we had two ideas for 
its contents. First, we would cover new and emerging technologies 
with tutorial articles and standardization updates. Second, we would 
explain existing (“old”) technologies and protocols and show how they 
could be used to build modern internets. Over the years there has 
been a mix of both types of articles in this journal, perhaps with a 
slight bias towards the “new” at the expense of the “old.” This month, 
we begin a new series of articles under the heading “Back to Basics.” 
From time to time, we will bring you articles about well-established 
techniques and technologies, the fundamentals of networking. Our 
first installment is a tutorial on the Internet Transport Layer (TCP 
and UDP) and is adapted from a forthcoming book on network man- 
agement by Keith McCloghrie and Marshall Rose. 


Networking continues to be a growth industry world wide. This 
month, we look at DANTE and EuropaNET, an effort to establish a 
pan-European research network. The article is by Josefien Bersee. 


If you want access to most of the tools on the Internet (FTP, Telnet, 
WWW, Gopher, etc.), you need IP connectivity in one form or another. 
The simplest and cheapest way to gain such access is to use SLIP or 
PPP with a dialup connection from your workstation (PC) to your 
service provider. Billy Barron compares a number of public domain 
SLIP and PPP drivers starting on page 16. 


As more and more businesses join the Internet, the question of elec- 
tronic commerce becomes important. NetCash is a framework for 
electronic currency being developed at USC-ISI. Gennady Medvinsky 
and Cliff Neuman give an overview of the system. 


The NetWorld+Interop 94 World Tour has begun. Last month in Las 
Vegas over 60,000 visitors attended the inaugural event, more than 
7,000 of them taking part in the tutorials, workshops or conference 
sessions. Visitors were able to see the first ever “Cyberstation” which 
broadcast sound, text and images live to the Internet. The exhibition 
featured the traditional InteropNet interconnecting the 600+ exhibit- 
ors, constructed with more than 300 miles of cable and 4,000 pieces 
of donated equipment. The World Tour continues in Berlin (June 
6-10), Tokyo (July 25-29), Atlanta (September 12-16), and finally 
Paris (October 24—28). For more information about these events, call 
1-800-INTEROP, 1-415-578-6900 or check out our WWW and Gopher 
servers on programs.interop.com. 


Finally, another reminder that we would like to hear from you. Send 
your suggestions, comments and questions to: ConneXions, 303 
Vintage Park Drive, Foster City, CA 94404-1138, USA. You can also 
reach us by fax: 415-525-0194 or e-mail: connexions@interop.com. 
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Back to Basics: 
The Internet Transport Layer 


by 
Keith McCloghrie, Cisco Systems and 
Marshall T. Rose, Dover Beach Consulting 


The transport layer is responsible for providing data transfer between 
end-systems to the level of reliability desired by the application. That 
is, the transport layer provides end-to-end service. 


In theory, the end-to-end needs of different applications can vary tre- 
mendously. In practice, however, there are really only two widely- 
used service paradigms: 


1. Reliable: in which the service offered is a “virtual pipeline”: 


e Stream-oriented: rather than dealing in packet exchanges, the 
end-to-end service provides a sequence of octets, termed a stream, 
to the application. 


e Full-duplex: the stream provided by the end-to-end service is bi- 
directional in nature. 


e Connection-oriented: before the stream can be used, a virtual 
connection is established between the two applications. 


e Application layer addressing: an application needs a means of 
identifying its peer on the remote system to which the stream 
should be connected. 


e In-sequence delivery: the end-to-end service guarantees that user- 
data is delivered in the same order in which it was sent. 


e User-data integrity: the end-to-end service guarantees that any 
user-data delivered has not been corrupted during network trans- 
mission. 


Graceful release: because user-data may be buffered both at the 
hosts and in the network, the end-to-end service will make sure 
that all of the data sent by the user is successfully transmitted 
before the stream is released. 


Note that these are general guidelines, and not fixed. In particular, 
the OSI CO-mode transport service, whilst offering a reliable trans- 
port paradigm, uses a packet-oriented (rather than stream-oriented) 
user-data paradigm, and has no graceful release mechanism (the 
functionality of which resides at the layer above). Regardless, the 
remaining characteristics are core to the concept of a reliable trans- 
port service. 


2. Unreliable: in which the service offered is virtually identical to that 
of the Internet datagram service. The only added features are: 


¢ Application layer addressing; and, 
e User-data integrity. 


It shouldn’t be surprising that the reliable service paradigm corre- 
sponds closely to a connection-oriented transport service, whilst the 
unreliable service paradigm is similar to a connectionless-mode trans- 
port service. 


The Internet suite of protocols provides two different transport proto- 
cols to meet these vastly different needs. Since both protocols use 
identical mechanisms to achieve application layer addressing and 
user-data integrity, the simpler protocol is described first. 


Application Layer 
Addressing 
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The User Datagram Protocol (UDP) is the connectionless-mode trans- 
port protocol in the Internet suite. As UDP is a transport layer 
protocol, for delivery, it uses the services of IP. If the protocol field of 
an IP datagram has the value 17 (decimal), the user-data contained in 
the datagram is a UDP packet: 


1 2 3 
01234567890123456789012345678901 
J] a aaa aa 


user-data 


Figure 1: A UDP Packet 


The meaning of these fields is straightforward: 


Source / destination port: identifies an application running at the 
corresponding IP address. 


¢ Length: the length of the UDP packet (header and user-data), 
measured in octets. 


e Checksum: a one’s-complement arithmetic sum, computed over a 
pseudo-header and the entire UDP packet. 


User-data: zero or more octets of data from the upper-layer proto- 
col. (Note that it is an artifact of the convention used in producing 
the figure above that this field appears to be a multiple of 4 octets 
in length. No such requirement is made by UDP.) 


The uses of these fields are now explained. 


To achieve application layer addressing, UDP manages 16-bit un- 
signed integer quantities, termed ports. Port numbers less than 512 
are assigned by the Internet Assigned Numbers Authority (IANA). 


These are termed well-known ports. In those cases when a service 
might be available over both TCP and UDP, the IANA assigns the 
same port number to that service for both protocols. 


On Berkeley UNIX, port numbers less than 1024 are reserved for 
privileged processes (an easily spoofed but, in some environments, 
useful security mechanism). 


The combination of an IP address and a port number is termed an 
internet socket which uniquely identifies an application-entity run- 
ning in an internet. 


Of course, the notion of application layer addressing is just another 
example of the multiplexing operation of protocols: 


e At the interface layer, each medium usually distinguishes between 
clients (entities at the internet layer) by using different values in 
a type field (e.g., Ethernet uses a value of 0x0800 to indicate IP); 


e At the internet layer, IP distinguishes between clients (entities at 
the transport layer) by using different values in a protocol field 
(e.g., IP uses a value of 17 to indicate UDP); and, 
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e At the transport layer, TCP and UDP distinguish between clients 
(entities at the application layer) by using different values in a 
port field (e.g., UDP uses a value of 161 (decimal) to indicate 
SNMP). 


The Assigned Numbers RFC lists the complete set of protocol num- 
bers used at all layers in the Internet suite of protocols. 


To achieve both user-data integrity and modest protection against 
misbehavior at the layers below, UDP calculates a pseudo-header 
which is conceptually prefixed to the UDP packet. The checksum algo- 
rithm is then run over a block that looks like this: 

1 2 3 


0123456789012345 6789012345678901 


user-data 


Figure 2: Pseudo-header 


The fields of the pseudo-header are relatively self-explanatory: the 
source and destination fields are taken from the IP packet, the empty 
field is simply a zero-valued octet, the protocol field is the value used 
by IP to identify UDP (17 decimal), and the UDP length field is the 
length of the UDP packet. TCP also uses this 96-bit pseudo-header in 
its checksum calculation when achieving user-data integrity. 


The Transmission Control Protocol (TCP) is the connection-oriented 
transport protocol in the Internet suite. As TCP is a connection- 
oriented transport protocol, it goes through three distinct phases: 
connection establishment, data transfer, and connection release. To 
keep track of a particular connection, each TCP entity maintains a 
Transmission Control Block (TCB). This is created during connection 
establishment, modified throughout the life of the connection, and 
then deleted when the connection is released. 


TCP is best described as a finite state machine, which starts in the 
CLOSED state. As events occur (either activity from a user of TCP or 
from the network), the TCP entity performs some action and then 
enters a new state. The TCP state diagram is presented in Figure 3. 
(It is suggested that the reader study the text before examining the 
figure.) 


A connection enters the LISTEN state when an application tells TCP 
that it is willing to accept connections for a particular port number. 
This is termed a passive open. 


Sometime later, another application tells TCP that it wishes to estab- 
lish a connection to an IP address and port number which corresponds 
to the application which is listening. This is termed an active open. (It 
is possible for two application entities to simultaneously issue active 
opens for each other. In this case, a single TCP connection is estab- 
lished.) 


Data transfer 


Retransmission 
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When two TCP entities communicate, the exchanged units of data are 
termed segments. The format of a segment is presented later on. 
Segments are interpreted relative to a connection. In TCP, a con- 
nection is defined as the pairing of the two internet sockets. This 96- 
bit quantity (source IP address and TCP port, destination IP address 
and TCP port) uniquely identifies the connection in an internet. 


When an active open is attempted, the originating TCP entity com- 
putes an initial sequence number, which is a “starting number” for 
this direction of the new connection. The sequence number must be 
chosen carefully so that segments from older instances of this con- 
nection, which might be floating around the network, won’t cause 
confusion with this new connection. A SYN (synchronize) segment is 
then sent to the destination TCP entity. Upon receiving this segment, 
the destination TCP entity checks to see that an application is 
listening on the destination TCP port. If not, the connection is aborted 
by sending a RST (reset) segment. (In the interest of simplicity, Figure 
3 doesn’t show this transition, or any transition, involving an RST 
segment.) Otherwise, the destination TCP entity computes a sequence 
number for its direction, and sends this back in a SYN/ACK (synchro- 
nize/acknowledge) segment which acknowledges the sequence number 
for the originating TCP entity. 


Upon receiving this segment, the original TCP entity makes sure that 
its sequence number was acknowledged and, if all is well, sends an 
ACK segment back to acknowledge the sequence number for the 
destination TCP entity. 


This protocol interaction is termed a three-way handshake. Once the 
three-way handshake has been successfully concluded, the connection 
enters the data transfer phase. 


In the data transfer phase, user-data is sent as a sequence of octets, 
each of which is numbered, starting with the initial sequence number. 


Each segment specifies a window size (in octets) which may be sent in 
the other direction before an acknowledgement is returned. Each seg- 
ment sent by a TCP entity contains an implicit acknowledgement of 
all octets contiguously received thus far. Precisely stated, the ack- 
nowledgement field indicates the number of the next octet that is 
expected by a TCP entity. 


This windowing strategy allows the TCP entities to achieve a pipe- 
lining effect in the network, while at the same time providing a flow 
control mechanism. The pipelining effect increases throughput by 
keeping more data in the network, whilst the flow control mechanism 
prevents either TCP entity from overrunning the connection resources 
(such as buffers for user-data) of the other. 


The disadvantage of this approach is that if segments are re-ordered, 
this information cannot be conveyed in an acknowledgement. For 
example, if two segments are sent, and the first one is delayed, the 
receiving TCP entity cannot acknowledge the second segment until it 
receives the first. 


The discussion thus far has not considered loss or corruption of seg- 
ments. Each time a TCP entity sends a segment, it starts a retrans- 
mission timer. At some time in the future, one of two events will 
happen first: either an acknowledgement for the segment will be 
received, and the timer can be stopped; or, the timer will expire. In 
this latter case, the TCP entity retransmits the segment and restarts 
the timer. 
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Retransmission continues some number of times until eventually the 
TCP entity gives up and declares the transport connection to be 
aborted. That is, TCP emulates reliability through retransmission. 
The trick, of course, is knowing when to retransmit. If data is lost or 
corrupted in the network and the sending transport entity retrans- 
mits too slowly, then throughput suffers. If data is delayed or dis- 
carded due to congestion in the network and the transport entity 
retransmits too quickly then it merely adds to the congestion and 
throughput gets even worse! 


The reader should appreciate that because of the service offered by IP; 
a TCP entity cannot distinguish between lossy or congested networks. 
Hence, TCP uses one of several adaptive algorithms to predict the 
latency characteristics of the network, which may fluctuate consider- 
ably because of other traffic. 


The retransmission timeout usually varies for each segment, based on 
the recent history of latency and loss exhibited by the network. Work 
reported in [9, 10] suggests some novel, common sense insights into 


this problem. 


passive OPEN CLOSE 
create TCB delete TCB 
active OPEN 
CLOSE create TCB 
delete TCB snd SYN 


rcv SYN 
snd SYN,ACK 


rcv SYN,ACK 


rev ACK of SYN 
ee snd ACK 


CLOSE WAIT 


CLOSE 
snd FIN 


LAST ACK 


rcv ACK of FIN 


FINWAIT-1 


rcv ACK of FIN 


FINWAIT-2 


rcv FIN 
snd ACK 


CLOSING i 


rev ACK of FIN 


timeout | 
TIME WAIT CLOSED ı 
E 4 


Figure 3: TCP State Diagram 
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As might be expected, acknowledgements and retransmission interact 
with the window strategy. Once again, suppose two segments are 
sent, and the first segment is lost. The receiving TCP entity cannot 
acknowledge the second segment. The retransmission timer expires 
for the sending TCP entity. It must now decide whether to retransmit 
the first segment or both segments. If it retransmits both segments, 
then it is “guessing” that both segments were lost. If this isn’t the 
case, then network bandwidth is being wasted. Otherwise, if it re- 
transmits the first segment only, it must wait for an acknowledge- 
ment to see if the second segment also needs to be retransmitted. If 
not, it has reduced its sending throughput by waiting for a roundtrip 
transaction in the network. 


In addition to trying to optimize network traffic, a TCP entity may try 
to reduce the overhead of communicating with local application enti- 
ties. This is usually achieved by buffering user-data in the TCP entity, 
both as it is received from the local application, in order to efficiently 
use the network, and also as user-data is received from the network, 
in order to efficiently communicate with the local application. Because 
of this, an application might need a mechanism for ensuring that all 
data it has previously sent has been received. 


This is accomplished using a PSH (push) function. When sending, an 
application may indicate that data previously sent should be pushed. 
The local TCP entity sets a PSH bit in the next new segment it sends. 
Upon receiving such a segment, the remote TCP entity knows that it 
should push user-data up to its own application. 


Although the push function must be present in each TCP implement- 
ation, few implementations of applications actually use this function- 
ality. This is because most TCP entity implementations will periodic- 
ally push any queued data towards the destination. Further, it should 
be noted that there are no semantics associated with the push 
function. It is simply a way of telling TCP to deliver all data previous- 
ly sent to the remote application. On the remote end, the application 
will see only the user-data and won’t receive any explicit indication of 
the push function having been invoked. Experience has shown that 
the push function is largely an internal matter: application protocols 
should be designed so that the push function isn’t used. 


Finally, TCP supports the concept of urgent data. The semantics of 
urgent data are application-specific. What TCP does is to indicate 
where urgent data ends in the stream. The receiving application, 
upon being notified that urgent data is present in the stream, can 
quickly read from the stream until the urgent data is exhausted. 


When an application indicates that it has finished sending on the 
connection, the local TCP entity will send all outstanding data, set- 
ting the FIN (finish) indication in the last segment to indicate that it is 
finished sending new data. 


Upon receiving this indication, the remote TCP entity will send an 
ACK for the FIN, and will inform (using a local mechanism) the 
application. When that application indicates that it too has no more 
data to send, a FIN is generated in this direction also. When all data 
in transit and the segments containing the FINs have been acknow- 
ledged, the two TCP entities declare the connection released. In order 
to ensure that old, duplicate packets don’t interfere with new con- 
nections being established between the two application entities, one of 
the TCPs will delay releasing the connection by twice the maximum 
segment lifetime. 
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Instead of requesting a graceful release, an application may deter- 
mine that it wishes to immediately abort the connection. In this case, 
the local TCP entity generates a RST (reset) segment, and the con- 
nection is immediately released. Any data in transit is lost. 


When TCP wishes to send a segment, it uses the services of IP. If the 
protocol field of an IP datagram has the value 6 (decimal), the user- 
data contained in the datagram is a TCP segment: 


1 2 3 


01234567890123456789012345678901 
[Po E S 


user-data 


Figure 4: The TCP segment 


The meaning of these fields is straightforward: 


Source / destination port: identifies an application running at the 
corresponding IP address. 


Sequence number: the number of the first octet of user-data in this 
segment. 


Acknowledgement number: if the ACK bit is set in the flags field, 
then this field indicates the next sequence number that the TCP 
entity is expecting to receive. 


Offset: the length of the TCP segment in 32-bit words (the mini- 
mum allowed value is 5). 


Flags: control bits indicating special functions of this segment. 


Window: the number of octets of user-data (starting with the octet 
indicated in the acknowledgement field), which the TCP entity is 
willing to accept. 


Checksum: a one’s-complement arithmetic sum, computed over a 
pseudo-header and the entire TCP segment, as discussed earlier. 


Urgent pointer: if the URG bit is set in the flags field, then this 
field, when added to the sequence number field, indicates the first 
octet of non-urgent data. 


Options: a collection of zero or more options. 


Padding: zero to three octets used to pad the segment header to a 
32-bit boundary. 


User-data: zero or more octets of data from the upper-layer proto- 
col. (Note that it is an artifact of the convention used in producing 
the figure above that this field appears to be a multiple of 4 octets 
in length. No such requirement is made by TCP.) 
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DANTE company 
structure 


Profile: DANTE and EuropaNET 
by Josefien Bersee, DANTE 


For many years the introduction of cross-border network services 
between European countries was the result of independent, bilateral 
agreements between pairs of national organisations, each of which 
had their own technical goals and administrative constraints. RARE 
(Réseaux Associés pour la Recherche Européenne) was created in 1986 
as a forum for the European national networking organisations to 
resolve the problems of interworking between those national services. 


The first ideas about the creation of a pan-European service provider 
offering international services appeared in the late 1980s. It was not 
however until 1991 that a task force was established under the aus- 
pices of RARE. The first blueprint for such an organisation was estab- 
lished quite quickly and by December 1991 a specific proposal had 
been produced for the creation of a limited liability company with 14 
European National Research Networks as shareholders. In February 
1993 the company DANTE was established; the acronym stands for 
Delivery of Advanced Network Technology to Europe. It was formally 
launched and took on its first employees on 5 July 1993. 


The choice of a limited liability company was made for both legal and 
financial reasons. As the sums of money involved in providing inter- 
national network services are significant it is important to have a 
commercial arrangement with the correct financial controls and limit- 
ation of risk. A limited liability company automatically limits risk and 
allows the control of expenditure to be related directly to the share- 
holders obligation to pay. Company control is exercised by sharehol- 
ders’ weighted voting, a reflection of shareholding size. Shareholdings 
fall into four categories, and are related to country size as measured 
by GNP. 


Shareholders - weighted voting 
(14 National Networks) 


Board members (5) 


General managers (2) 


Employees (11) —— 


Figure 1: DANTE Company Structure 


Figure 1 illustrates the company’s structure. The shareholders are 
represented by a board of five members. The two joint general man- 
agers were appointed in the Summer of 1993; 9 other staff have been 
recruited since, covering the following areas: Network Planning and 
Development (2), Network Management and Customer Liaison (2), 
Applications Planning and Development (2), Customer and Public 
Relations (1) and General Support and Administration (2). 


The gestation of 
EuropaNET 


Services 
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The X.25 part of EuropaNET originated in the IXI (International 
X.25 Infrastructure) Pilot network, which provided connectivity at 64 
Kbps between countries participating in the CEC COSINE Project 
(concluded in April 1993) from July 1990 onwards. COSINE, con- 
strained by its internal organisational procedures and technical orien- 
tation towards OSI protocols, was overtaken to some extent by the 
explosion of usage of TCP/IP in Europe, the result of which was the 
setting up of the Ebone IP backbone in 1992. 


In the specification and tender for a 2Mbps production service to 
supersede IXI, it had already been determined to be essential that the 
new backbone should handle multiple protocols. The result of the ten- 
der was the setting up in October 1992 of the European Multi- 
Protocol Backbone (EMPB) as the pan-European component of Europa- 
NET which offered a 2Mbps service in all COSINE member states. 
DANTE’s own transatlantic capacity was added to the EuropaNET 
service at the beginning of 1994. 


EuropaNET and Ebone have coexisted since; a comparison of the 
“styles” of both services is presented in Table 1. 


DANTE - EuropaNET 


Managed service, specified 
in detail and contracted to 
professional operational 
suppliers (including the 
national research networks). 


Quality of Service (availability, 
performance) defined in speci- 
fications and operational 
contract. 


Imposition of Management 
Discipline (labelled bureau- 
cracy by technicians). More 
orderly (but slower) progress. 


Predictable behaviour, 
performance dependable 
(even if not high). 


Ebone 


Coordinated service, taking 
advantage of latest develop- 
ments; development and 
operations closely linked. 


Best efforts—usually very 
committed—maximum use 

of capacity given priority over 
performance for individual 
user. 


Try it and see if it works; 
if so OK, if not then deal 
with problem. Rapid adop- 
tion of new techniques. 


Actual performance un- 
predictable, depends on 

load imposed by others; 

priorities determined by 
technicians rather than 
users. 


Table 1: DANTE/EuropaNET versus Ebone 
organisation and service characteristics 


Today EuropaNET offers an international connectivity package con- 


sisting of three components: 


1. A pan-European backbone linking the European research networks: 
EuropaNET’s main technical and/or value adding features are: 


e IP-IP with the external routing protocols EGP and BGP3 (BGP4 


is about to be tested) 


e CLNP-CLNP with Static Routing and the Inter-Domain Routing 


Protocol IDRP 


e X.25/X.75 interconnections 
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DANTE and EuropaNET (continued) 
e [P—X.25/X.75 interconnections 
e CLNP-X.25/X75 interconnections 
e IP/CLNP policy based routing 
e Address authentication & accounting for IP, CLNP and X.25/ X.75 


e High-quality network management and help desk service avail- 
able 24 hours per day, 7 days per week, with fault handling and 
escalation in accordance with agreed procedures 


Service Level Agreements: 


- Network service availability guarantee, including availability 
of access lines; 


- Guaranteed end-to-end throughput and delays 


The EuropaNET backbone nodes are normally installed in each coun- 
try where there is a point of attachment. At each node location there 
may be one or more nodes. Each node is connected to at least two 
other nodes and each node location is connected to at least two other 
node locations, up to now in two different countries. Nodes are pre- 
sent in nearly all western-European countries and in a growing num- 
ber of Eastern European countries. DANTE is cooperating with the 
CEC’s PHARE program to extend EuropaNET eastwards. 


The main building blocks in the node equipment are the INMOS 
Transputer from SGS Thomson Microelectronics and the XPC con- 
troller from Motorola. The Transputer provides true parallel pro- 
cessing with very low switching delays and high switching capacity. 
With the current version of the Transputer and XPC controller, tran- 
sit delays are 0.7 msecs, access delays are 4 msecs and nodes can be 
built up to switch several hundred thousand packets per second. 


The system is capable of handling trunk line speeds of 8Mbps with 
full utilisation of the bandwidth. At the end of 1992 a new version of 
the INMOS Transputer, the T9000, was released. With an appropri- 
ate line interface the T9000 is capable of handling 34Mbps trunk and 
8Mbps access lines. 


2. A gateway to other European countries and services: 


For a transitional period, access to a further group of European coun- 
tries and services—not yet connected to EuropaNET—is available via 
a gateway to Ebone. The gateway is located in Amsterdam and oper- 
ates at 2Mbps. 


3. Connections from Europe to other continents: 


Transatlantic connections have historically been provided on a bi- 
lateral basis between the US and individual European countries. In 
order to cater for the needs of those countries which do not have their 
own intercontinental circuits, DANTE has provided two interconti- 
nental circuits to the USA, an E1 (2Mbps) circuit between Amsterdam 
and Washington and a T1 (1.5Mbps) circuit between Geneva and 
Washington. 


Lines to Germany, Italy and the UK are currently managed inde- 
pendently of EuropaNET but the national networks concerned have 
agreed to integrate them with the EuropaNET service for routing and 
backup purposes. 


EuropaNET (Backbone) Access Points 


Country Network _ Capacity 
Austria ACONET 64 kbps 
Belgium BELNET 2 Mbps 
CEC 64 kbps 
DCS 64 kbps 
JRC-GEEL 64 kbps 
RESULB 64 kbps 
Czech Rep. CESNET 64 kbps 
Denmark DATAPAK 64 kbps 
France TRANSPAC 64 kbps 
Germany WIN 2 Mbps 
Greece ARIADNET 64 kbps 
HELLASPAC 64 kbps 
Hungary HUNGARNET 64 kbps 
TUB 64 kbps 
PLEASE 64 kbps 
Ireland HEANET 64 kbps 
EIRPAC 64 kbps 


EuropaNET* 


Lines ordered or planned, January 1994 
*EuropaNET is trademark of DANTE 


Lie 


NORDUNET 


IF 
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LEGEND 
© NODE 
M2 Mbps —— 64 kbps 
=m i5 Mbps = SCC kbps 
— Mbps ——+? providing service to 
Country Network ___ Capacity 
Italy GARR 2 Mbps 
JRC/ISPRA 64 kbps 
ITAPAC 9.6 kbps 
Luxembourg RESTENA 64 kbps 
LUXPAC 64 kbps 
Netherlands SURFNET 2 Mbps 
N1 64 kbps 
ESAPAC 64 kbps 
Portugal RCCN 64 kbps 
TELEPAC 64 kbps 
Romania ICI 9.6 kbps 
PUB 9.6 kbps 
Slovenia ARNES 128 kbps 
SIPAX.25 64 kbps 
Spain REDIRIS 2 Mbps 
IBERPAC 64 kbps 


Korea 


Country Network Capacity 
Sweden NORDUNET 64 kbps 
Switzerland SWITCH 2 Mbps 
CERN 1 Mbps 
UK JANET 2 Mbps 
Gateway EuropaNET-Ebon 
Amsterdam 2 Mbps 
Intercontinental connectivit 
Amsterdam - Washington 2 Mbps 
Geneva/CERN - Washington 1.5 Mbps 
London - Korea 64 kbps 


Figure 2: EuropaNET topology in January 1994 
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NORDUnet has indicated its intention of doing the same with the 
US-Stockholm line when it switches from Ebone to EMPB in June 
1994. DANTE is currently discussing the opportunities for rational- 
ising intercontinental connectivity with the other European circuit 
operators with the aim of increasing total capacity in a cost effective 
way. 


In the course of 1994 DANTE will also be providing intercontinental 
connectivity to Korea—a contract for this was signed in January 
between DANTE and the CEC—and Canada. It is reviewing the possi- 
bility of a new direct connection between Europe and Japan. 


The establishment of EuropaNET was a milestone in the development 
of European research networking. However, a network access capacity 
of 2Mbps is still only the beginning, in particular when European 
national networks are starting to operate national services at 34Mbps 
and higher speeds. The introduction of these services will create a 
demand for complementary international facilities. DANTE has taken 
up the challenge to define and procure a 34Mbps and 155Mbps back- 
bone for the European research community. 


A challenge indeed, taking into account the political and technical 
setting in Europe. A major outstanding issue for the development of 
European research networking remains the lack of a “central” funding 
and support organisation (equivalent to the Federal Government in 
the US) whose responsibilities cover the whole of Europe. Without 
such an organisation to take initiatives and to seed the creation of a 
new infrastructure, the collection of necessary funds is a significant 
management challenge. 


The setting up of a high speed backbone represents an opportunity to 
extend the capacity of the existing backbone. In addition, new devel- 
opments in the area of network technology and in particular the 
deployment of Asynchronous Transfer Mode (ATM) offer the possibil- 
ity for European researchers to gain early experience of the benefits 
and new applications which ATM will enable. Other important issues 
to be tackled are topology planning, connectivity requirements to 
other continents, options with respect to management, operation and 
payment of the service, and an assessment of relevant applications. 


In addition to providing the pan-European backbone network service 
DANTE organises a range of Value Added Applications. Foremost 
among these is the X.400 Mail Coordination Service, MailFLOW. The 
Service was established to ensure the efficient interworking of the 
X.400 e-mail services provided by the national research networks. 


MailFLOW coordinates activities between and among the national 
networks and offers a single information and contact point for the 
international MHS community. The MailFLOW team, at the Swiss 
national network SWITCH, maintains an information server with 
operational documentation such as routing tables and mapping 
tables, provides trouble-ticket and monitoring functions, supports new 
MHS services and organises communication between MHS managers, 
both through e-mail and meetings. 


As well as mail coordination, plans are well advanced to build on the 
pilot directory service PARADISE set up as part of the COSINE 
Project. DANTE is preparing to offer a coordinated international 
directory service from May 1994. 
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DANTE?’s other important area of activity in the field of Value Added 
Applications is Information Services. This is a particularly chal- 
lenging issue. More than any other area, information services are 
regarded as “free.” Neither users nor funding bodies are eager to pay 
charges that DANTE, with its commercial structure, is obliged to 
make for all its services. In practice the costs associated with 
operation of an Information Service platform are significant as is the 
data management overhead. As a consequence, quality of service and 
topicality of data are very variable. DANTE is committed to offer cost- 
based, unbundled prices and to avoid cross subsidy. Information 
services are more than just a simple technical challenge within this 
commercial environment. 


The requirement of a liaison desk in support of the international ser- 
vice package was part of the blueprint for the setting up of DANTE. A 
particular need was identified for centralising support for Europa- 
NET. DANTE’s liaison desk, DANTEAM, started operating in the 
Spring of 1994. 


DANTEAM will act as liaison between Unisource—the company oper- 
ating the EuropaNET backbone—and staff at the operational depart- 
ments of the national networks. A trouble-ticket system will be used 
to register and contribute to the resolution of reported problems. As 
DANTE’s involvement with network development and management 
gradually grows, operational and administrative responsibilities will 
increase as well. The liaison desk will play a central role in imple- 
menting and coordinating this process. Despite its predominant tech- 
nical orientation, the liaison desk will also be a first point of contact 
with regard to Application Services. 


After seven years of coordination efforts in European research net- 
working DANTE has appeared on the stage to look after the inter- 
national networking needs of the European research community. The 
company has been successful in the first half year of its existence and 
a firm basis now exists from which new services can be developed. 
While RARE will continue to coordinate technical discussions of devel- 
opment needs, DANTE organises, purchases and manages services on 
behalf of its customers, the national research networks in Europe. 


A number of people in DANTE have provided input for this article, in 
particular joint General Managers Howard Davies and Dai Davies. 
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A Brief Comparison of Public Domain 
SLIP/PPP Drivers for MS-DOS 


by Billy Barron, University of Texas at Dallas 


The University of Texas at Dallas (UTD) is considering installing 
SLIP and PPP down the road. In preparation for this, I decided to do 
some testing before any of our equipment was installed. After some 
tests, I definitely decided that all SLIP, CSLIP (Compressed SLIP), 
and PPP packages for MS-DOS machines were not created equal. 


My first requirement was that the package had to be public domain so 
we could distribute it free to our users. My second requirement was 
that it needed to provide a packet driver or ODI interface to the 
higher level applications. 


On the PC end, I have a 386 25Mhz with 64Kb cache and 1 MB of 
memory. My modem was a MultiTech MultiModem II and I kept the 
configuration of the modem with faculty settings because I figured 
that most users out there would do the same. The MultiModem II is a 
V.32/V.32bis/V.42/V.42bis. 


On the remote end, I used the facilities of Texas Metronet, who I owe 
thanks to for helping me perform some of these tests. On their end, I 
was going through a Livingston PortMaster Terminal Server to reach 
an HP 705 known as “feenix” which served as the SLIP, CSLIP and 
PPP host. Feenix is a workhorse running interactive users and acting 
as a news server. This may have caused some variance in my tests. 


Finally, I used my workstation on the UTD campus called “frog” as 
my connection point for FTP, Telnet and ping. I used the initial Rut- 
gers version of CUTCP for FTP and Telnet. The package has two ways 
to FTP and the TN3270 program fails back to VT100 when appropri- 
ate. I utilized the FTP server built into TN3270 as well as TN3270 for 
my Telnet connections. The ping was part of the WATTCP package. 
Frog is a SuperWorkstation 50Mhz SuperStation II clone. The con- 
nection between Metronet and Frog is at Ethernet speeds. 


I will start by giving some background on the packages I attempted to 
use. 


e SLIP8250: I found this SLIP driver in the Crynwr packet driver 
distribution. 


e EtherSLIP: A modified SLIP8250 that supports Ethernet packets. 


¢ Slipper: Slipper was written by Peter Tattum who is also respon- 
sible for the newsreading package Trumpet. 


e Cslipper: A compressed SLIP version of Slipper. 
e UMSLIP: The University of Minnesota SLIP package. 


e EtherPPP: A PPP driver developed by University of Michigan and 
Merit. 


¢ Kermit: This is only included for comparison purposes. 


In all cases, I spent some test trying to optimize the particular pack- 
age. 


The purpose of the FTP test was to show the raw data transfer rate 
for the various drivers. The results should also be useful in estimating 
performance of tools like Mosaic. 


The Interoperability Report 


In this test, I downloaded three files. The first was a random Post - 
Script document called Save.ps. The second was a compressed ZIP 
2.0 file. The final was the ASCII MS-Kermit documentation. I down- 
loaded the files three times and averaged the results. 


In theory, we should see that Compressed SLIP performs the best 
since it compresses TCP/IP headers. Second should be PPP because it 
does the same compression, but it adds an additional three bytes, 
which should make a very minor difference in the numbers. In last 
place we should find SLIP. 


SLIP8250 Slipper © UMSLIP UMSLIP 


6 EtherSLIP 1.4 1.4 2.0 
Save.ps 
55,81 1b Tan | #5 | 409 | cena | Te 
ASCII Slow 1.32K/s | 1.36K/s 1.33K/s 
zman01.zip Too 
559.23s | 503.90s 569.03s 
767,529b Crashed 
Dl a 1.34K/s | 1.49K/s 1.31K/s 
ckuker.doc Too 194.51s | 170.24s 18 
i i 9.61s 
251,390b Slow | 1.29K/s | 1.48K/s | Crashed | 4.33K/s 
ASCII 
Cslipper EtherPPP 
1.4 1.9.37beta Kermit 
aaie | 22088 | 30.26: | aaan 
TECI 1.67K/s | 1.80K/s | 1.38K/s 
— oP 475.64s | 487.91s | 851.86s 
BINARY 1.57K/s | 1.54K/s | 0.88K/s 
ckuker.doc | 442.675 | 134.62s | 169.97s 
rs oa 1.76K/s | 1.85K/s | 1.44K/s 


Figure 1: FTP Performance Results 


To start with SLIP8250 with CUTCP was transferring the file too 
slow for me to complete the tests in a reasonable amount of time. It 
was my best guess that would have taken hours to complete the trans- 
fer. The other problem was UMSLIP 1.4 which crashed the connection 
during the tests every single time. 


In the SLIP category, Slipper won hands down against EtherSLIP 
and UMSLIP 2.0. As expected, Cslipper beat all SLIP drivers. Ether- 
PPP unexpectedly beat Cslipper in two out of three of the files. 
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Comparison of SLIP/PPP Drivers (continued) 


The purpose of the ping test was to measure interactive responsive- 
ness. From Telnet, it was nearly impossible to really say if one driver 
was more responsive than another. 


The ping tests turned out to not be very useful. All of the packages 
except one had ping times of .10 or .11 seconds. That package was 
EtherPPP which had a disappointing .26 second result. Unfortun- 
ately, I have not been able to figure out why EtherPPP was slower. It 
should be noted that EtherPPP seemed no slower when using Telnet 
than any of the other drivers. 


After the tests, I decided that really only three of the packages are 
worthy of further consideration. First, if you are in a situation where 
you only have SLIP access, then use Slipper. Otherwise use either 
Cslipper or EtherPPP depending on your needs. However, you probab- 
ly should run your own performance evaluation especially since some 
of the drivers are still being refined. 


[1] C. Partridge, “Dialup IP,” ConneXions, Volume 3, No 11, Novem- 
ber 1989. 


[2] J. Romkey, “A Nonstandard for Transmission of IP Datagrams 
over Serial Lines: SLIP,” RFC 1005, June 1988. 


[3] D. Perkins, “The Point to Point Protocol: A proposal for Multi- 
protocol Transmission of Datagrams over Point to Point Lines,” 
RFC 1134, 1989. 


[4] D. Perkins & R. Hobby, “The Point to Point Protocol Initial 
Configuration Options,” RFC 1172, July 1990. 


[5] R. Hobby, “The Point to Point Protocol (PPP)—A new proposed 
standard Serial Line Protocol,” ConneXions, Volume 4, No. 4, 
April 1990. 


[6] J. Romkey, “SLIP: Serial Line IP,” ConneXions, Volume 2, No. 5, 
May 1988. 


[7] J. Romkey, “The Packet Driver,” ConneXions, Volume 4, No. 7 : 
July 1990. 


[8] R. Coop, “SLIP Interoperability,” ConneXions, Volume 6, No. 6, 
June 1992. 


[9] R. Coop & B. Tompsett, “An Investigation of SLIP and Dialup 
SLIP,” Research Report 91/3, Department of Computer Science, 
University of Hull, November 1991. 


[10] R. Coop & B. Tompsett, “Current Commercial and Public Imple- 
mentations of SLIP, Dialup SLIP and PPP for SunOS UNIX 
Systems and IBM Compatible PCs,” Report for the UK Internet 
Consortium, Department of Computer Science, University of 
Hull, November 1991. 


[11] Finseth, C., “SLIP at the University of Minnesota,” ConneXions, 
Volume 7, No. 1, January 1993. 


BILLY BARRON has an M.S. in Computer Science from the University of North 
Texas. He also worked there for many years until he recently transferred to the 
University of Texas at Dallas. In parallel, he has worked on the CICNet Electronic 
Journal Archive, but recently resigned to have more free time. Also, he has the co- 
author ofa famous guide to libraries on the Internet. E-mail: billy@utdallas.edu 


Abstract 


Requirements 


The Interoperability Report 


NetCash: Electronic Currency for the Internet 


by Gennady Medvinsky and B. Clifford Neuman, 
University of Southern California 


NetCash is a framework for electronic currency being developed at the 
Information Sciences Institute of the University of Southern Califor- 
nia. NetCash will enable new types of services on the Internet by pro- 
viding a real-time electronic payment system that satisfies the diverse 
requirements of service providers and their users. Among the proper- 
ties of the NetCash framework are: security, anonymity, scalability, 
acceptability, and interoperability. 


One of the primary goals of NetCash is to facilitate anonymous elec- 
tronic payments over an unsecure network without requiring the use 
of tamper-proof hardware. NetCash is designed to provide secure 
transactions in an environment where attempts at illegal creation, 
copying, and reuse of electronic currency are likely. In order to protect 
the privacy of parties to a transaction, NetCash provides financial in- 
struments that prevent traceability and preserve the anonymity of 
users. 


Furthermore, with NetCash, service providers and their users are 
able to select payment mechanisms based on the level of anonymity 
desired, ranging from non-anonymous and weakly anonymous in- 
struments that are scalable, to unconditionally anonymous instru- 
ments that require more resources of the currency server. NetCash 
provides scalable electronic currency that is accepted across multiple 
administrative domains. 


Using the NetCash framework, parties that are customers of different 
banks can accept each other’s currency. To provide interoperability ac- 
ross currency servers, NetCash integrates anonymous electronic cur- 
rency into the non-anonymous electronic banking infrastructure that 
has been proposed for routine transactions. This article presents an 
overview of NetCash; a more detailed description can be found in [3]. 


Among the desirable properties for an electronic currency system are: 
security, anonymity, scalability, acceptability, and interoperability. 


e Security: Forging paper currency is difficult. Unfortunately, elec- 
tronic currency is just data and is easily copied. Copying or double 
spending of electronic currency should be prevented or detected. 
Ideally the illegal creation, copying, and reuse of electronic cash 
should be unconditionally or computationally impossible. Some 
systems rely instead on post-fact detection and punishment of 
double spending [1]. 


e Anonymity: The identity of an individual using electronic currency 
should be protected; it should not be possible to monitor an indi- 
vidual’s spending patterns, nor determine one’s source of income. 
An individual is traceable in traditional transaction systems such 
as checks and credit cards. Some protocols are unconditionally un- 
traceable, where an individual’s spending cannot be determined 
even if all parties collude [1]. For some transactions, weaker 
forms of anonymity may be appropriate, e.g., traceability can be 
made difficult enough that the cost of obtaining such information 
outweighs the benefit. 
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Electronic Currency for the Internet (continued) 


e Scalability: A system is scalable if it can handle the addition of 
users and resources without suffering a noticeable loss of perform- 
ance. The existence of a central server through which transactions 
must be processed limits the scale of the system. The mechanisms 
used to detect double spending also affect scalability. Most pro- 
posed e-cash protocols assume that the currency server will record 
all coins that have been previously spent and check this list when 
verifying a transaction [1,5,6]. This database will grow over time, 
increasing the cost to detect double spending. Even if the life of a 
coin is bounded, there is no upper bound on the amount of storage 
required since the storage requirement depends on the rate at 
which coins are used, rather than on the number of coins in circul- 
ation. 


e Acceptability: Most e-cash proposals use a single bank [1,5,6]. In 
practice, multiple banks are needed for scalability, and because 
not all users will be customers of a single bank. In such an envir- 
onment, it is important that currency minted by one bank be 
accepted by others. Without such acceptability, electronic curren- 
cy could only be used between parties that share a common bank. 
When currency minted by one bank is accepted by others, recon- 
ciliation between banks should occur automatically. To our know- 
ledge, NetCash is the first system that satisfies this requirement. 


e Interoperability: Users of the Internet will select financial instru- 
ments that best suit their needs for a given transaction. It is like- 
ly that several forms of electronic currency will emerge, providing 
different tradeoffs for security, anonymity, and scalability. In such 
an environment it is important that funds represented by one 
mechanism be easily convertible into funds represented by others. 


The NetCash infrastructure is based on independently managed, 
distributed currency servers that provide a point of exchange between 
anonymous electronic currency and non-anonymous instruments such 
as electronic checks. In the framework, checks based on the global 
accounting infrastructure [4] support the transfer of funds between 
currency servers, forming a financial federation where currency min- 
ted by different servers is accepted. An organization wishing to set up 
and manage a currency server obtains insurance for the new currency 
from an agency similar to the United States Federal Deposit Insur- 
ance Corporation (FDIC); the currency is backed by account balances 
registered to the currency server in the non-anonymous accounting 
infrastructure. A certificate of insurance allows the coins minted bya 
currency server to be accepted across administrative domains. 


Figure 1 shows a financial federation consisting of several accounting 
servers (AS1, AS2 and AS3) and several currency servers (CS1 and 
CS2). The accounting servers maintain accounts for the currency ser- 
vers and other clients. Funds can be transferred between currency 
servers when one (the payor) issues a check authorizing another (the 
payee) to transfer funds from the payor’s account to that of the payee. 
The accounting hierarchy allows the clearing of such checks between 
the accounting servers that maintain the accounts for the respective 
currency servers. Although the currency servers are identified in such 
transactions, the end-users are not. 


Electronic currency 
transaction 
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Such transfers provide for anonymous currency transactions between 
users in different administrative domains. To verify a coin issued by 
another currency server, a user’s local currency server contacts the 
remote currency server to convert the coin, accepting in return a 
check payable to the local currency server. This check is then cleared 
through the global accounting infrastructure, and a new coin issued 
by the local currency server is returned to the user. 


AS3 
Account Server 3 


accounts: AS1, AS2 


AS2 
Account Server 2 


accounts: AS3, CS2 


AS1 
Account Server 1 


accounts: AS3, CS1 


CS1 
Currency Server | 


<e-coins, e-checks> CS2 
Currency Server 2 


Figure 1: Financial federation 


NetCash provides a framework for integrating currency servers using 
different electronic currency protocols, providing a range of anonymity 
guarantees. Electronic currency mechanisms providing unconditional 
or weak anonymity can be tied to the framework. Hither the payor, 
the payee, or both parties may remain anonymous. The integration of 
multiple mechanisms allows a tradeoff between the anonymity guar- 
antees and the resulting overhead of the electronic currency mecha- 
nism. Economic incentives can be used to encourage the selection of 
an appropriate mechanism. 


Chaum and others have proposed protocols supporting uncondition- 
ally untraceable electronic currency [1]. While those protocols may be 
used within the framework we are developing, we have chosen to 
concentrate our efforts on protocols that provide weaker anonymity 
guarantees. The protocols we are developing are described briefly 
here; additional detail is available in [3]. 


cS 


(currency server) 


Protocol steps SKan A’s freshly generated secret key 
SK B’s freshly generated secret ke 
1. { coins, SKay, Kay, S_id} Kp BN BRE T 7 
2 ins. SK ion) Kes Currency server’s public key 
: i st t ‘ 
t coins BN; transaction} Keg Kp Bs public key 
3. {instrument} SKpn 4 Tae 
4 T id. date}Ke-! } SK Kg B’s private key 
. t , dat : z 
ae ee Kan A’s freshly generated public session key 
S_id Service identifier 


T_id Unique identifier 


Figure 2: Protocol for routine monetary transactions using NetCash 
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Electronic Currency for the Internet (continued) 


Figure 2 on the previous page shows a protocol for routine monetary 
transactions using NetCash. A payment is made by A (the payor) to B 
(the payee). A remains anonymous and Bis protected from fraud. It is 
assumed that A can determine B’s public key and B can determine the 
public key of the currency server. In the first step, A sends coins, the 
identifier of the desired service S_id, and two keys, a freshly gene- 
rated secret key SK, and a public session key K ‘aw all encrypted in 
B’s public key. B records the newly chosen secret key SK,y which will 
be used to establish a secure channel with A at a later time. A public 
session key can also be used to verify that subsequent requests origin- 
ate from the principal that paid for the service. 


After receiving coins from A, B verifies the validity of the coins with 
the currency server. In the second step, Bsends to the currency server 
the coins, SK, a newly chosen secret key, and an indication of what it 
wants back: new coins known to be valid, or a check made payable to 
a named principal. This message is encrypted in the currency servers 
public key. Upon receiving the coins, the currency server verifies the 
validity of the coins. If the coins haven’t been spent already, the ser- 
ver returns the desired instrument sealed with SK „y In the final step, 
B returns a receipt signed with its private key and encrypted with 
SK y. The receipt includes amount paid, date and a unique identifier 
T_id that will be used along with the session key to obtain the service. 


One shortcoming of this protocol as described is that it provides pro- 
tection from fraud only by the payor. B can spend A’s coins without 
providing a valid receipt. Extensions to the protocol supporting pro- 
tection against fraud for both parties, anonymity provisions for the 
payee, and partially offline transactions are described by the authors 
in [3]. 


Several security projects are under way at ISI that provide the neces- 
sary infrastructure for NetCash. One project is developing a proxy 
mechanism using the Kerberos authentication system [7]. This mecha- 
nism provides the authorization services needed for the non- 
anonymous accounting infrastructure that connects currency servers. 
Work is also under way to develop the accounting databases that are 
needed for the non-anonymous accounting infrastructure and the 
currency databases needed by electronic currency servers. 
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CONNEXIONS 


Overview 


Tutorials, 
demonstrations and 
posters 


Topics 


Call for Papers 


The Network Services Conference 1994 (NSC ’94) will be held Novem- 
ber 28-30 1994 in London, England. 


Open computer networking is no longer the sole domain of univer- 
sities and research institutions. Today, governments, schools, public 
organizations, commercial enterprises and private individuals are 
actively using and supplying information over the global Internet. 


How will these various network communities cooperate and interact? 
How will the academic and research community adapt to the new net- 
work reality? How will the network and networking tools now avail- 
able stand up to the explosion in number of users and amount of infor- 
mation available? How will we train novices? What will we pay for 
and what will be for free as the commercialization of the network 
progresses? Will we be inundated by advertising over the net? These 
are only a few of the questions facing network service providers and 
users alike. 


Building on the success of the previous Network Services Conferences 
in Pisa (1992) and Warsaw (1993), NSC ’94 will focus on the issue of 
providing services to customers, with special attention paid to the 
exciting developments in global tools and services. We will address 
the impact of the new global tools on service development and sup- 
port, the changing function of traditional tools and services (such as 
archives), new services (such as multi-media communications), the 
future role of the library and the effects of commercialization on net- 
works and network services. Customer support at all levels, and the 
role of support in accessing global services, will also be covered. Talks, 
tutorials, demonstrations and other conference activities will address 
the needs of the research, academic, educational, governmental, 
industrial, and commercial network communities. 


NSC ’94 is being organized by the EARN (European Academic and 
Research Network) Association in cooperation with the Internet Soci- 
ety, RARE, NORDUnet and EUnet. 


In addition to the presentation of papers, there will be tutorial ses- 
sions on specific network services as part of the regular conference 
program. A room will be available for workstations and PCs to be 
used for demonstrations throughout the conference. 


A poster wall will be available to participants for the display of their 
posters and projects. Terminals with connectivity to the Internet will 
be available to delegates. 


The Program Committee for NSC ’94 is soliciting proposals for papers, 
tutorials, demonstrations and posters in all fields related to network 
services. Subject areas for presentations include, but are not limited 
to, the following: 


e Network resource tools 

e Network directory services 

e Multimedia Communications 

¢ Electronic Publishing 

e Libraries and Networking 

e Special Interest Communities 

e Groupware, Cooperative Work over the Network 
e Networking for Schools 


Submissions 


Further information 
and general inquiry 


Important dates 
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e User Support 

e Delivering Services to the Desktop 

e Quality of Network Services 

e Commercialization of Network Services 

¢ Businesses on the Network 

e Providing Network Services to New Countries and Communities 
Papers and proposals for tutorials, demonstrations or posters, includ- 


ing a short biography and an abstract should be sent by mail, fax or 
preferably by e-mail, to: 


NSC 794 

EARN Office 

PSI — Batiment 211 

91405 Orsay CEDEX 

FRANCE 

Fax: +33 16941 6683 

E-mail: NSC94@EARNCC. EARN. NET or NSC94GEARNCC .BITNET 


The official language of the conference will be English. 


Further information will be available through the conference mailing 
list, NSC94-L@EARNCC.EARN.NET (or NSC94-L@EARNCC.BITNET). If 
you want to make sure you receive registration information as well as 
the preliminary program and other information of interest to confer- 
ence participants, join the list by sending e-mail to: 


LISTSERV@EARNCC .EARN.NET 
or 

LISTSERVG@GEARNCC . BITNET 
with the line: 

SUB NSC94-L Your Name 


Conference information is also available from the EARN anonymous 
ftp server (ftp.earn.net) and from the EARN Gopher server at 
gopher.earn.net. 


If you have any questions or require any assistance, you can contact 
the conference organizers at: 


NSC 794 

EARN Office 

PSI — Batiment 211 
91405 Orsay CEDEX 


FRANCE 

Tel.: +33 16941 2426 

Fax: +33 16941 6683 

E-mail: NSC94@EARNCC.EARN.NET or NSC94GEARNCC . BITNET 
Deadline for papers: July 1, 1994 
Deadline for demonstrations and posters: September 16, 1994 


Notification of acceptance (papers/tutorials): August 1, 1994 
Notification of acceptance (posters/demos): September 30, 1994 
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CONNEAIONS 


Topics 


Format 


Submissions 


Call for Participation 


The Workshop on Mobile Computing Systems and Applications will be 
held December 8-9, 1994 at the Dream Inn in Santa Cruz, California. 
The event is sponsored by the IEEE Computer Society TCOS in co- 
operation with ACM SIGOPS and the USENIX Association. 


A major challenge of this decade is the effective exploitation of two 
symbiotic technologies: portable computers and wireless networks. 
Harnessing these technologies will dramatically change the compu- 
ting landscape. But realizing the full potential of the resulting mobile 
computing systems will require advances in many areas such as: 


e Hardware 

e Communications 

e Scalability 

e Power Management 
e Security 

e Data Access 

e User Interfaces 

e Location Sensitivity 


The goal of this workshop is to foster exchange of ideas in mobile com- 
puting among workers in the field. Attendance will be limited to about 
60 participants, based on the position papers submitted. Submissions 
should be fewer than five pages in length and may expose a new prob- 
lem, advocate a specific solution, or report on actual experience. 


In addition, we will be hosting a small number of novel hardware and 
software exhibits relevant to mobile computing. The exhibits may be 
research prototypes or commercial products. Interested parties should 
submit technical descriptions of their exhibits. 


Online copies of the position papers will be made available via anony- 
mous FTP prior to the workshop. A printed proceedings will be pub- 
lished after the workshop, and mailed to participants. 


A small number of graduate students will be granted a waiver of the 
registration fee. In return, these students will be required to take 
notes at the workshop and help put together the proceedings. Stu- 
dents who wish to be considered for the waiver must send in a brief 
description of their current research, and an explanation of how parti- 
cipation in the workshop is likely to help them. 


Send (10 x) position papers to: Send exhibit descriptions to: 
M. Satyanarayanan Peter Honeyman 
School of Computer Science CITI 
Carnegie Mellon University University of Michigan 
Pittsburgh, PA 15213 Ann Arbor, MI 48103-4943 
Phone: +1 412-268-3743 Phone: +1 313-763-4413 
Fax: +1 412-681-5739 Fax: +1 313-763-4434 
E-mail: satya@cs.cmu.edu E-mail: honey@citi.umich.edu 
Submissions due: August 20, 1994 
Acceptance Notification: October 1, 1994 
Camera-ready copy due: November 15, 1994 


Format 


Topics 


Submission guidelines 


Important dates 
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Call for Papers 


Interop Company is soliciting technical papers for an Engineer’s 
Conference to be held as part of the upcoming NetWorld+Interop 94 
Paris event, October 24—28, 1994, in Paris. 


The Engineers Conference, which will be held on Thursday/Friday 
October 27-28, is a two-day focused event offering approaches and 
solutions to practical systems and software design for networking. All 
participants in the conference will be able to attend the NetWorld+ 
Interop 94, Paris exhibition, which will run from October 26-28. 


The conference will feature the presentation of original papers which 
will have been selected by a review committee. All accepted papers 
will be published in Conference Proceedings. Accepted papers must be 
presented by original authors during the 2-day conference. Conference 
sessions typically will be 90 minutes long and will present three 
papers of 20 to 30 minutes duration. 


The Engineer’s Conference will concentrate on engineering design 
problems in three areas: High Speed Networking, Internetworking, 
and Multimedia. The conference seeks to bring together research scho- 
lars, engineers, and vendors to address pragmatic engineering issues 
in the field of networking and distributed systems interoperability. It 
is an excellent forum for engineers and researchers to publish papers 
and to be brought up to date on solutions to today’s engineering rel- 
ated problems. Papers are solicited in the following areas: 


e High Speed Networking: ATM, Fast Ethernet, SDH, FDDI-II, 
HIPPI, SMDS, Frame Relay, Broadband ISDN, etc. 


e Internetworking: Addressing Schemes, Routing Protocols, Support 
of Mobility, Design of Bridges, Routers, and Multiprotocol Brou- 
ters, Application Gateways etc. 


e Multimedia Networking: Multimedia technologies, Multimedia 
interoperability, Packet Video and Voice, Multimedia Mail and 
Conferencing, Tele-Presence, Virtual Reality, etc. 


Interested authors are invited to submit an abstract (up to 600 words) 
clearly describing the problem and the solution offered. Authors of 
accepted abstracts must submit the paper before the last date. These 
papers are reviewed by a technical committee for technical merit of 
the paper before final acceptance. Final camera-ready papers must 
not exceed 10 A4 pages. All abstracts must contain the authors name, 
address, telephone number, Fax number and e-mail address (if 
available). Please send your abstract to: 


Interop Europe 

14 Place Marie-Jeanne Bassot 
92593 Levallois Peret Cedex 
Paris 

FRANCE 

Attention: Engineer’s Conference 


or e-mail it (ASCII or PostScript) to: Paris_Engineer@interop.com 
(E-mail submission is preferred.) 


Abstracts due: June 3, 1994 (Send it today!) 
Notification to authors: June 24, 1994 

Draft paper due: July 22, 1994 

Feedback to authors: August 5, 1994 


Camera-ready copy due: September 9, 1994 
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